In recent years, as the wireless technology matures, more people are using wireless devices to access networks, and the desire to access networks anytime and anywhere is increasing. Supporting mobile communication becomes an inevitable requirement for the development of networking. Numerous studies on how a network provides mobility support has been done, among which, PMIPv6 (Proxy Mobile IPv6) of IETF (Internet Engineering Task Force), as a localized mobility management technology, the mobility management function is shifted from the terminal side to the network side, so that the network represents the host to manage the IP mobility, and a mobile entity in the network is responsible for tracking the moving of the host and initiating the required mobile signals transmission. In PMIPv6, the IP (Internet Protocol) mobility of the host is achieved without the host participating in any mobility-related signal transmission, thereby the burden of the terminal is greatly alleviated, and the centralized control is facilitated.
In another aspect, multicast technology is increasingly used in various fields widely. Multicast is a way of point-to-multipoint information transmission, and requires that data can be transmitted simultaneously from one source node to multiple destination nodes which constitute a particular set of nodes (also known as a group or cluster). Due to its advantages, such as high network utilization rate, reduced backbone network congestion, saved resource, and strong scalability, the multicast technology plays an important role in new type network applications, such as video conferencing, document distributing, real-time information distributing, and IP TV. In a typical mobile IPTV (Interactive Personality TV) application, a large number of users can obtain audio/video stream data distributed via a network by the multicast technology.
With the development of mobile communication technology, the combination of mobility and multicasting becomes an urgent requirement. In the mobile environment, since the wireless link has limited bandwidth and high error rate, and a mobile node has limited energy supply, processor capability and the like, new challenges to the traditional multicast technology have been arised. The traditional multicast protocol is based on a fixed-network, wired-communication mode, and can not meet the requirement for mobility. Mobile multicast architecture not only needs to deal with dynamic changes of the mobile host's position, but also needs to deal with group memberships which dynamically change in the multicast group. Generally speaking, the multicast architecture in the mobile environment needs to meet the following requirements: seamless continuity of multicast dialogues in the event of node handover; optimal routing of data packets; stream handover support in multicast communication (different streams have different characteristics and identifiers); avoiding specialization of the multicast solution (supporting only multicast, not unicast); having capability of dealing with packet loss and duplicate copies; multicast data stream dynamically adapting to the states of the current network (to adjust the sending rate, etc.); easy to be deployed; accelerating the convergence speed of the routing protocol and the like.
Currently, the studies on supporting multicast source mobility by the IETF are still in the initial stage, and a solution of supporting multicast source mobility in PMIPv6 has been proposed. This solution includes RPT (Rendezvous Point Tree) and SPT (Shortest Path Tree) based methods in PMIPv6.
With the solution, in the case where multicast data are transmitted in the RPT mode, a LMA (Local Mobility Anchor) is used as a RP (Rendezvous Point) to reply a Join message sent by a multicast receiving node, and to establish a shortest path multicast tree from the LMA to the multicast receiving node. Multicast data are sent to the LMA by a multicast source, and then forwarded to the multicast receiving node along the multicast tree by the LMA. In this mode, when the multicast source moves, there is no need to re-establish the shortest path tree from the LMA to the multicast receiving node, so the multicast tree is relatively stable. However, in this mode, since the path forwarding multicast data by the LMA is not the optimal routing from the multicast source to the multicast receiving node, significant delay and network burden may be introduced.
In the RPT mode, after a multicast source MN enters into a PMIPv6 domain, a procedure is performed as shown in FIG. 1, and the procedure mainly includes the following steps.
In step 101, a link between a Mobile Access Gateway MAG1 and a multicast source MN is established, and the multicast source MN includes “S”=1 and “J”=1 in a RS (Router Solicitation) message to identify that the multicast source MN is a multicast source and a RPT mode is selected.
In step 102, the MAG1 sends an extended PBU message to a LMA, and establishes a bidirectional tunnel between the MAG1 and the LMA when it is determined that the multicast source MN is attached to the MAG1.
In step 102, on receipt of the PBU message, the LMA analyzes extended information contained in the PUB message, and replies a multicast Join message.
In step 103, multicast data are sent to the LMA by the multicast source MN in the basic manner defined in PMIPv6.
In this step, an SPT between the LMA and a multicast receiving node is established, and multicast data are transmitted between the LMA and the multicast receiving node in accordance with the multicast routing protocol.
In step 104, the multicast source MN moves to an MAG2, and sends multicast-related information to the MAG2 using the RS message.
In step 105, a bidirectional tunnel between the LMA and the MAG2 is updated.
In step 105, the SPT between the LMA and the multicast receiver is not affected in the process of updating the bidirectional tunnel between the LMA and the MAG2.
When the multicast source MN is switched, multicast data are transmitted continually. The moving of the mobile multicast source does not affect the multicast receiver.
With the solution, in the case where multicast data is transmitted in the SPT mode, the multicast source replies a Join message sent by a multicast receiving node, and establishes directly a shortest path multicast tree from the multicast source to the multicast receiving node, and multicast data are sent directly to the multicast receiving node along the established multicast tree. In this mode, network delay is shorter due to the optimization of the routing, but the router storage burden will be too heavy and the multicast tree will be unstable. When the multicast source moves in the network, the multicast tree needs to be updated frequently.
In the SPT mode, after a multicast source MN enters into a PMIPv6 domain, a procedure is performed as shown in FIG. 2, and the procedure mainly includes the following steps.
In step 201, a link between an MAG1 and a multicast source MN is established, and the multicast source MN includes “S”=1 and “J”=0 in a RS message to identify that the multicast source MN is a multicast source and a RPT mode is selected.
In step 202, the MAG1 sends an extended PBU message to a LMA, and establishes a bidirectional tunnel between the MAG1 and the LMA when it is determined that the multicast source MN is attached to the MAG1.
In step 202, on receipt of the PBU message, the LMA analyzes extended information contained in the PBU message but does not reply a multicast Join message.
In step 203, multicast data are sent to the LMA by the multicast source MN in the basic manner defined in PMIPv6.
In step 203, when the LMA redirects the multicast Join message to the multicast source MN, an SPT between the multicast source and a multicast receiving node begins to be established, and the subsequent multicast data are transmitted between the multicast source and the multicast receiving node along the optimized path.
In step 204, the multicast source MN sends, after moving to an MAG2, multicast-related information to the MAG2 using the RS message.
In step 205, a bidirectional tunnel between the LMA and the MAG2 is updated.
In step 205, the SPT between the multicast source and the multicast receiving node also needs to be updated when the bidirectional tunnel between the LMA and the MAG2 is updated, because the root node of the multicast tree moves to a different position.
As defined in the solution, the multicast source selects the mode in accordance with a moving speed. If a multicast source moves in the network at a lower speed, a shortest path multicast tree is established between the multicast source and a multicast receiving node in the manner of SPT; and if the multicast source moves faster in the network, the shortest path multicast tree is established between the LMA and a multicast receiving node in the manner of RPT and by taking the LMA acting as a rendezvous node.
The disadvantages of the prior art lie in that it can not support a fast handover of the multicast source, and a large delay happens if the multicast source is switched between two MAGs in a PMIPv6 domain. As prescribed in the existing solution, it is needed to perform the processes, such as binding, updating, and authenticating, and particularly it is needed to perform the process of reconstructing the multicast tree in the SPT mode, when the multicast source moves from an old MAG (i.e., the MAG1) to a new MAG (i.e., the MAG2). Multicast data distribution may be continued only when these processes are completed, this causes long time interruption of multicast service. Since the feature of one-to-multiple in the multicast service, the handover delay of the multicast source will affect all users within the group, it is obvious that the seamless continuity of the multicast dialogues is not satisfied, and in particular, the applications with real-time requirement are affected seriously.